Customized diameter performance metrics

ABSTRACT

Various exemplary embodiments relate to a method performed by a Diameter node, the method including: receiving a Diameter message at the Diameter node; evaluating a custom metric rule to identify a metric to be collected; and collecting the metric related to the received Diameter message based upon the evaluation of the custom metric rule.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to the following co-pending applications,which are hereby incorporated by reference for all purposes as if fullyset forth herein: application Ser. No. 13/482,690, filed on May 29,2012, “ORGANIZATION OF DIAMETER ROUTING AGENT RULE SETS;” applicationSer. No. 13/482,587, filed on May 29, 2012, “ROUTING DECISION CONTEXTOBJECTS;” application Ser. No. 13/602,579, filed on Sep. 4, 2012, “RULEENGINE EVALUATION OF CONTEXT OBJECTS;” and application Ser. No.13/962,071, filed on Aug. 8, 2013, Attorney Docket No. ALC 3895,“GENERIC PERSISTENCE IN A DIAMETER ROUTING AGENT.”

TECHNICAL FIELD

Various exemplary embodiments disclosed herein relate generally tocommunication networks.

BACKGROUND

Since its proposal in Internet Engineering Task Force (IETF) Request forComments (RFC) 3588, the Diameter protocol has been increasingly adoptedby numerous networked applications. For example, the Third GenerationPartnership Project (3GPP) has adopted Diameter for various policy andcharging control (PCC), mobility management, and IP multimedia subsystem(IMS) applications. As IP-based networks replace circuit-switchednetworks, Diameter is even replacing SS7 as the key communicationssignaling protocol. As networks evolve, Diameter is becoming a widelyused protocol among wireless and wireline communications networks.

3GPP networks may include various types of Diameter nodes, e.g., policyand charging rules nodes (PCRNs), Diameter routing agents (DRAs), etc.Such Diameter nodes may include a metrics sub-component used to measurevarious aspects of performance within the products. The metrics may givethe network operator a view of what the system is doing. For example,the metrics sub-component counts events processed, including Diameterrequests and LDAP requests, recording the average latency andthroughput. Any system overload events may also be recorded as metrics.CPU, memory, network and disk utilization may all be recorded asmetrics.

SUMMARY

A brief summary of various exemplary embodiments is presented below.Some simplifications and omissions may be made in the following summary,which is intended to highlight and introduce some aspects of the variousexemplary embodiments, but not to limit the scope of the invention.Detailed descriptions of a preferred exemplary embodiment adequate toallow those of ordinary skill in the art to make and use the inventiveconcepts will follow in later sections.

Various exemplary embodiments relate to a method performed by a Diameternode, the method including: receiving a Diameter message at the Diameternode; evaluating a custom metric rule to identify a metric to becollected; and collecting the metric related to the received Diametermessage based upon the evaluation of the custom metric rule.

Various exemplary embodiments relate to a Diameter node (DN) forprocessing a Diameter message, the DN including: a rule storageconfigured to store a custom metrics rule that defines a custom metricsscenario; a Diameter stack configured to receive a Diameter message fromanother Diameter node; a rule engine configured to evaluate the custommetric rule to identify a metric to be collected; and a metricscollector configured to collect the metric related to the receivedDiameter message based upon the evaluation of the custom metric rule.

Various exemplary embodiments relate to a non-transitorymachine-readable storage medium encoded with instructions for executionby a Diameter node (DN) for processing a Diameter message, the mediumincluding: instructions for receiving a Diameter message at the Diameternode; instructions for evaluating a custom metric rule to identify ametric to be collected; and instructions for collecting the metricrelated to the received Diameter message based upon the evaluation ofthe custom metric rule.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand various exemplary embodiments, referenceis made to the accompanying drawings, wherein:

FIG. 1 illustrates an exemplary network environment including Diameternodes;

FIG. 2 illustrates an exemplary Diameter node;

FIG. 3 illustrates an exemplary hardware diagram of a Diameter node;

FIG. 4 illustrates an embodiment of a custom metric rule;

FIG. 5 illustrates an embodiment of a method of applying custom metricsrules.

To facilitate understanding, identical reference numerals have been usedto designate elements having substantially the same or similar structureor substantially the same or similar function.

DETAILED DESCRIPTION

The description and drawings merely illustrate the principles of theinvention. It will thus be appreciated that those skilled in the artwill be able to devise various arrangements that, although notexplicitly described or shown herein, embody the principles of theinvention and are included within its scope. Furthermore, all examplesrecited herein are principally intended expressly to be only forpedagogical purposes to aid the reader in understanding the principlesof the invention and the concepts contributed by the inventor(s) tofurthering the art, and are to be construed as being without limitationto such specifically recited examples and conditions. Additionally, theterm, “or,” as used herein, refers to a non-exclusive or (i.e., and/or),unless otherwise indicated (e.g., “or else” or “or in the alternative”).Also, the various embodiments described herein are not necessarilymutually exclusive, as some embodiments can be combined with one or moreother embodiments to form new embodiments. As used herein, the terms“context” and “context object” will be understood to be synonymous,unless otherwise indicated.

A Diameter node may include a metrics sub-component that records metricsfor numerous predetermined scenarios, however, the possible scenariosthat could be of interest is virtually limitless. It is impractical (ifnot impossible) to hard-code/predetermine every single scenario torecord metrics for. It is also impractical to continue selecting asubset of scenarios to support, as different network operators will havedifferent needs regarding metrics collection. Accordingly there remainsa need for customizing the metrics recorded on a network operator siteto reflect the uniqueness of each network operator deployment. Describedbelow is a method and a system that allows a network operator to collectcustom metrics. This method and system may take advantage of a ruleengine implemented in the Diameter node. Such rule engine may have otheruses as well, for example, evaluating policy decisions and implementingpolicy rules, providing Diameter routing using a DRA, etc. Because sucha rule engine may already be present in Diameter nodes, it may beleveraged to provide a solution to providing custom metric collection inthe Diameter nodes as specified by a network operator or user.

FIG. 1 illustrates an exemplary network environment including Diameternodes. Exemplary network environment 100 may be a subscriber network forproviding various services. In various embodiments, subscriber network100 may be a public land mobile network (PLMN). Exemplary subscribernetwork 100 may be telecommunications network or other network forproviding access to various services. Exemplary subscriber network 100may include user equipment 110, base station 120, evolved packet core(EPC) 130, packet data network 150, and application function (AF) 160.

User equipment 110 may be a device that communicates with packet datanetwork 150 for providing the end-user with a data service. Such dataservice may include, for example, voice communication, text messaging,multimedia streaming, and Internet access. More specifically, in variousexemplary embodiments, user equipment 110 is a personal or laptopcomputer, wireless email device, cell phone, tablet, television set-topbox, or any other device capable of communicating with other devices viaEPC 130.

Base station 120 may be a device that enables communication between userequipment 110 and EPC 130. For example, base station 120 may be a basetransceiver station such as an evolved nodeB (eNodeB) as defined by therelevant 3GPP standards. Thus, base station 120 may be a device thatcommunicates with user equipment 110 via a first medium, such as radiowaves, and communicates with EPC 130 via a second medium, such asEthernet cable. Base station 120 may be in direct communication with EPC130 or may communicate via a number of intermediate nodes (not shown).In various embodiments, multiple base stations (not shown) may bepresent to provide mobility to user equipment 110. Note that in variousalternative embodiments, user equipment 110 may communicate directlywith EPC 130. In such embodiments, base station 120 may not be present.

Evolved packet core (EPC) 130 may be a device or network of devices thatprovides user equipment 110 with gateway access to packet data network140. EPC 130 may further charge a subscriber for use of provided dataservices and ensure that particular quality of experience (QoE)standards are met. Thus, EPC 130 may be implemented, at least in part,according to the relevant 3GPP standards. EPC 130 may include a servinggateway (SGW) 132, a packet data network gateway (PGW) 134, and asession control device 140.

Serving gateway (SGW) 132 may be a device that provides gateway accessto the EPC 130. SGW 132 may be one of the first devices within the EPC130 that receives packets sent by user equipment 110. Variousembodiments may also include a mobility management entity (MME) (notshown) that receives packets prior to SGW 132. SGW 132 may forward suchpackets toward PGW 134. SGW 132 may perform a number of functions suchas, for example, managing mobility of user equipment 110 betweenmultiple base stations (not shown) and enforcing particular quality ofservice (QoS) characteristics for each flow being served. In variousimplementations, such as those implementing the Proxy Mobile IPstandard, SGW 132 may include a Bearer Binding and Event ReportingFunction (BBERF). In various exemplary embodiments, EPC 130 may includemultiple SGWs (not shown) and each SGW may communicate with multiplebase stations (not shown).

Packet data network gateway (PGW) 134 may be a device that providesgateway access to packet data network 140. PGW 134 may be the finaldevice within the EPC 130 that receives packets sent by user equipment110 toward packet data network 140 via SGW 132. PGW 134 may include apolicy and charging enforcement function (PCEF) that enforces policy andcharging control (PCC) rules for each service data flow (SDF).Therefore, PGW 134 may be a policy and charging enforcement node (PCEN).PGW 134 may include a number of additional features such as, forexample, packet filtering, deep packet inspection, and subscribercharging support. PGW 134 may also be responsible for requestingresource allocation for unknown application services.

Session control device 140 may be a device that provides variousmanagement or other functions within the EPC 130. For example, sessioncontrol device 140 may provide a Policy and Charging Rules Function(PCRF). In various embodiments, session control device 140 may includean Alcatel Lucent 5780 Dynamic Services Controller (DSC). Sessioncontrol device 140 may include a DRA 142, a plurality of policy andcharging rules blades (PCRBs) 144, 146, and a subscriber profilerepository. The DRA 142 and PCRBs 144, 146 are Diameter nodes.

As will be described in greater detail below, DRA 142 may be anintelligent Diameter Routing Agent. As such, DRA 142 may receive,process, and transmit various Diameter messages. DRA 142 may include anumber of user-defined rules that govern the behavior of DRA 142 withregard to the various Diameter messages DRA 142 may encounter. Based onsuch rules, the DRA 142 may operate as a relay agent, proxy agent, orredirect agent. For example, DRA 142 may relay received messages to anappropriate recipient device. Such routing may be performed with respectto incoming and outgoing messages, as well as messages that are internalto the session control device.

Policy and charging rules blades (PCRB) 144, 146 may each be a device orgroup of devices that receives requests for application services,generates PCC rules, and provides PCC rules to the PGW 134 or otherPCENs (not shown). PCRBs 144, 146 may be in communication with AF 160via an Rx interface. As described in further detail below with respectto AF 160, PCRB 144, 146 may receive an application request in the formof an Authentication and Authorization Request (AAR) from AF 160. Uponreceipt of an AAR, PCRB 144, 146 may generate at least one new PCC rulefor fulfilling the application request.

PCRB 144, 146 may also be in communication with SGW 132 and PGW 134 viaa Gxx and a Gx interface, respectively. PCRB 144, 146 may receive anapplication request in the form of a credit control request (CCR) fromSGW 132 or PGW 134. As with an AAR, upon receipt of a CCR, PCRB 144, 146may generate at least one new PCC rule for fulfilling the applicationrequest. In various embodiments, the AAR and the CCR may represent twoindependent application requests to be processed separately, while inother embodiments, the AAR and the CCR may carry information regarding asingle application request and PCRB 144, 146 may create at least one PCCrule based on the combination of the AAR and the CCR. In variousembodiments, PCRB 144, 146 may be capable of handling bothsingle-message and paired-message application requests.

Upon creating a new PCC rule or upon request by the PGW 134, PCRB 144,146 may provide a PCC rule to PGW 134 via the Gx interface. In variousembodiments, such as those implementing the proxy mobile IP (PMIP)standard for example, PCRB 144, 146 may also generate QoS rules. Uponcreating a new QoS rule or upon request by the SGW 132, PCRB 144, 146may provide a QoS rule to SGW 132 via the Gxx interface.

Subscriber profile repository (SPR) 148 may be a device that storesinformation related to subscribers to the subscriber network 100. Thus,SPR 148 may include a machine-readable storage medium such as read-onlymemory (ROM), random-access memory (RAM), magnetic disk storage media,optical storage media, flash-memory devices, and/or similar storagemedia. SPR 148 may be a component of one of PCRB 144, 146 or mayconstitute an independent node within EPC 130 or session control device140. Data stored by SPR 148 may include subscriber information such asidentifiers for each subscriber, bandwidth limits, charging parameters,and subscriber priority.

Packet data network 150 may be any network for providing datacommunications between user equipment 110 and other devices connected topacket data network 150, such as AF 160. Packet data network 150 mayfurther provide, for example, phone or Internet service to various userdevices in communication with packet data network 150.

Application function (AF) 160 may be a device that provides a knownapplication service to user equipment 110. Thus, AF 160 may be a serveror other device that provides, for example, a video streaming or voicecommunication service to user equipment 110. AF 160 may further be incommunication with the PCRB 144, 146 of the EPC 130 via an Rx interface.When AF 160 is to begin providing known application service to userequipment 110, AF 160 may generate an application request message, suchas an authentication and authorization request (AAR) according to theDiameter protocol, to notify the PCRB 144, 146 that resources should beallocated for the application service. This application request messagemay include information such as an identification of the subscriberusing the application service, an IP address of the subscriber, an APNfor an associated IP-CAN session, or an identification of the particularservice data flows that must be established in order to provide therequested service.

As will be understood, various Diameter applications may be establishedwithin subscriber network 100 and supported by DRA 142. For example, anRx application may be established between AF 160 and each of PCRBs 144,146. As another example, an Sp application may be established betweenSPR 148 and each of PCRBs 144, 146. As yet another example, an S9application may be established between one or more of PCRBs 144, 146 anda remote device implementing another PCRF (not shown). As will beunderstood, numerous other Diameter applications may be establishedwithin subscriber network 100.

In supporting the various potential Diameter applications, DRA 142 mayreceive Diameter messages, process the messages, and perform actionsbased on the processing. For example, DRA 142 may receive a Gx CCR fromPGW 134, identify an appropriate PCRB 144, 146 to process the Gx CCR,and forward the Gx CCR to the identified PCRB 144, 146. DRA 142 may alsoact as a proxy by modifying the subsequent Gx CCA sent by the PCRB 144,146 to carry an origin-host identification pointing to the DRA 142instead of the PCRB 144, 146. Additionally or alternatively, DRA 142 mayact as a redirect agent or otherwise respond directly to a requestmessage by forming an appropriate answer message and transmitting theanswer message to an appropriate requesting device.

A Diameter node may include a metrics sub-component that records metricsfor numerous predetermined scenarios, however, the possible scenariosthat could be of interest is virtually limitless. It is impractical (ifnot impossible) to hard-code/predetermine every single scenario torecord metrics for. It is also impractical to continue selecting asubset of scenarios to support, as different network operators will havedifferent needs regarding metrics collection. The metric to be collectedmay include, for example, message source, message destination,application, message type, command, result code, message counts,processor throughput and latency, message latency, etc.

Current Diameter nodes, e.g., DRA, PCRN, etc., may include a metricssub-component used for measuring various aspects of performance withinthe Diameter nodes. The metrics may provide the network operator a viewof what the system is doing. For example, the metrics sub-component maycount events processed, including Diameter requests and LDAP requests,recording the average latency and throughout. Any system overload eventsmay also be recorded as metrics. Further, CPU, memory, network and diskutilization may all be recorded as metrics.

Each metric scenario may be identified by a set of conditions describingthe scenario for which the metric has been recorded and a collection ofname-value pairs identifying the metrics to collect. For example ametric scenario for a particular Diameter message type might include{Application=Gx, Command=CCR, Request type=Initial, OriginHost=MyOriginHost, Origin Realm=MyOriginRealm}. As a result, counts,latencies, throughput, etc., may be recorded against very specificscenarios including various conditions, in this case against the messagetype and where the message originated from.

Previously, metric scenarios and metric attributes were hard-coded. Thehard-coded set of metric attributes may now be extended by addingadditional name-value pairs to the metric to be recorded in a specificmetric scenario. Further, additional metric scenarios and theirassociated metrics may also be defined for collecting metrics in theDiameter nodes.

The metrics sub-component may provide an application programminginterface (API) for registering one or more metric attribute name-valuepairs against the event currently being processed. Once the event hasbeen processed to completion, the metrics sub-component may record themetrics taking into account any custom metric attributes that wereregistered for that event during processing. As a result, more granularmetrics may be recorded that may provide more insight to what isoccurring in the system.

The Diameter nodes may include a rule engine that may be used to recordcustomized metrics. While the embodiments described herein use a ruleengine that may process other types of rules (e.g., policy rules,routing rules, overload rules, etc.) in the Diameter node, a metricsspecific rule engine may also be used separate from the rule enginesfound in the Diameter nodes for processing other types of rules.

Below examples of custom metrics are described.

On a DRA, the primary job of the node is to route Diameter messages tothe correct destination. The algorithm for determining the destinationfor the Diameter message may be written in the form of routing rules inthe rule engine. The routing decision may be made by interrogating thecontent of the Diameter message alone, or the rules may have to retrievemore information from some other source (e.g., transient storage,persistent storage, external client). The rules author may choose to addadditional conditions to assign a unique scenario metric attribute(name-value pair) to each scenario. For example, a custom scenariometric attribute {“Routing”, “Message Only”} may be used when therouting decision is to be made by looking at the Diameter message only,and another custom scenario metric attribute {“Routing”, “Transient”}may be used when the routing decision must refer to some transientinformation.

On a PCRN, predefined metrics scenarios may specify the recording ofcount, latency, throughput per application (e.g., Gx), command (e.g.,CCR), and per a few other predetermined characteristics. Such predefinedmetrics are not very granular when considering the breadth offunctionality in the PCRN. A key feature in the PCRN is metering whichmay enable the network operator to monitor a subscriber's data usage andmodify the subscriber's level of service based on that usage.Accordingly, the network operator may manage their subscriber base andits level of service via rules in the PCRN rule engine. As in theprevious example, the rules author may write custom metric rules toassign custom metric attributes to coincide with other actions relatedto metering scenarios. For example, this may be an effective way for anetwork operator to determine how often their subscriber base crossescertain usage thresholds.

In another example, by default, metrics collection may make nodistinction between local and roaming subscribers. If desired, thenetwork operator may further refine the recording of metrics betweenlocal and roaming subscribers or some other subscriber category. Forexample, custom metric rules may define a scenario where usage and othercustom metric data for roaming users is collected. In addition, custommetric rules may define a scenario to collect similar custom metric datafor local subscribers, but the data collected may be different dependingupon the needs of the network operator.

In another example, a Diameter node may include support for an externalsubscriber repository (SPR). The Diameter node may use an SPRsub-component to interact with the external SPR. The SPR sub-componentmay use plugins to support a particular network operators external SPR.The plugin may include software supplied by the supplier of the SPR toprovide interaction with the SPR. Such plugins may be customized for thespecific component associated with the plugin. There may be scenarioswithin the plugin that are of interest from a metrics perspective.Accordingly, custom metric rules may be used to define scenarios whereunique metric data may be collected relating to the operation andinteraction with the SPR. One example of a metric to measure with theSPR is cache hits. Data from the SPR may be cached in the PCRN so thatrequests to the SPR for the data, which take longer, are not needed.Accordingly, a metric may be collected indicating whether SPR data wasobtained from a local cache or from a request to the SPR. Such data mayhelp to understand the latencies involved in accessing SPR data.

FIG. 2 illustrates an exemplary Diameter node (DN) 200. DN 200 may be astandalone device or a component of another system. For example, DN 200may correspond to DRA 142 or the PCRBs 144, 146 that act as a PCRN ofexemplary environment 100. In such an embodiment, DN 142 may supportvarious Diameter applications defined by the 3GPP such as, for example,Gx, Gxx, Rx, or Sp. It will be understood that DN 200 may be deployed invarious alternative embodiments wherein additional or alternativeapplications are supported. As such, it will be apparent that themethods and systems described herein may be generally applicable tosupporting any Diameter applications and messages of other protocolssuch as RADIUS, SS7 or HTTP/XML, among others.

DN 200 may include a number of components such as Diameter stack 205,message handler 210, rule engine 215, rule storage 220, user interface225, metrics collector 230, and metrics storage 235.

Diameter stack 205 may include hardware or executable instructions on amachine-readable storage medium configured to exchange messages withother devices according to the Diameter protocol. Diameter stack 205 mayinclude an interface including hardware or executable instructionsencoded on a machine-readable storage medium configured to communicatewith other devices. For example, Diameter stack 205 may include anEthernet or TCP/IP interface. In various embodiments, Diameter stack 205may include multiple physical ports.

Diameter stack 205 may also be configured to read and construct messagesaccording to the Diameter protocol. For example, Diameter stack may beconfigured to read and construct CCR, CCA, AAR, AAA, RAR, and RAAmessages. Diameter stack 205 may provide an application programmer'sinterface (API) such that other components of DRA 200 may invokefunctionality of Diameter stack. For example, rule engine 215 may beable to utilize the API to read an attribute-value pair (AVP) from areceived CCR or to modify an AVP of a new CCA. Various additionalfunctionalities will be apparent from the following description.

Message handler 210 may include hardware or executable instructions on amachine-readable storage medium configured to interpret receivedmessages and invoke rule engine 215 as appropriate. In variousembodiments, message handler 210 may extract a message type from amessage received by Diameter stack 205 and invoke the rule engine 215using a rule set that is appropriate for the extracted message type. Forexample, the message type may be defined by the application and commandof the received message. After evaluating one or more rules, rule engine215 may pass back an action to be taken or a message to be sent. Messagehandler 210 may then transmit one or more messages via Diameter stack205, as indicated by the rule engine 215.

Rule engine 215 may include hardware or executable instructions on amachine-readable storage medium configured to process a received messageby evaluating one or more rules stored in rule storage 220. As such,rule engine 215 may be a type of processing engine. Rule engine 215 mayretrieve one or more rules, evaluate criteria of the rules to determinewhether the rules are applicable, and specify one or more result of anyapplicable rules. The rules evaluated by the rule engine 215 may be oneof various types of rules, for example, policy rules, shedding rules,routing rules, context routing rules, or custom metrics rules. Thecustom metrics rules will be further described in more detail below.

Rule storage 220 may be any machine-readable medium capable of storingone or more rules for evaluation by rule engine 215. Custom metricsrules may be stored in the rule storage. Accordingly, rule storage 220may include a machine-readable storage medium such as read-only memory(ROM), random-access memory (RAM), magnetic disk storage media, opticalstorage media, flash-memory devices, and/or similar storage media. Invarious embodiments, rule storage 220 may store one or more rule sets asa binary decision tree data structure. Various other data structures forstoring a rule set will be apparent.

User interface 225 may include hardware or executable instructions on amachine-readable storage medium configured to enable communication witha user. As such, user interface 225 may include a network interface(such as a network interface included in Diameter stack 205), a monitor,a keyboard, a mouse, or a touch-sensitive display. User interface 225may also provide a graphical user interface (GUI) for facilitating userinteraction. User interface 225 may enable a user to customize thebehavior of DN 200. For example, user interface 225 may enable a user todefine custom metrics rules for storage in rule storage 220 andevaluation by rule engine 215. The user may also define other sorts ofrules for use by the rule engine 215 as well. Various additional methodsfor a user to customize the behavior of DN 200 via user interface 225will be apparent to those of skill in the art.

Metrics collector 230 may include hardware or executable instructions ona machine-readable storage medium configured to collect metrics data inthe metrics storage 235. The metrics collector 230 may include apredefined set of metrics scenarios and metrics to collect for thosescenarios. Based upon custom metrics rules evaluated by the rule engine,the metrics collector 230 may extend existing predefined metricsscenarios or even create additional metrics scenarios. The metricscollector 230 communicates with the message handler 210 and the diameterstack 205 in order to collect the desired metrics data. As the metricsdata is collected, it may be stored in the metrics storage for furtherprocessing or access by the network operator. The metrics collector 230may be or include the metrics sub-component described above.

Metrics storage 235 may be any machine-readable medium capable ofstoring metrics data collected by the metrics collector 230.Accordingly, metrics storage 235 may include a machine-readable storagemedium such as read-only memory (ROM), random-access memory (RAM),magnetic disk storage media, optical storage media, flash-memorydevices, and/or similar storage media. In various embodiments, metricsstorage 235 may store metrics data sets using various data structures aswill be apparent. Further, the metrics storage 235 may be part of therules storage 220 or any other available storage device on the DN 200.

Upon DN 200 receiving a Diameter message to be processed, messagehandler 210 may pass information regarding the Diameter message to therule engine 215. The rule engine 215 may determine if the message fitswithin any custom metrics scenarios as defined by custom metrics rules.If so, rule engine 215 may invoke the metrics collector to collect andstore the metrics data specified by the custom metrics scenarios. It ispossible that a single received Diameter message may fit within morethan one scenario based upon scenarios defined by the custom metricsrules. Accordingly, the rule engine 215 may direct the metrics collector230 to collect and store data for these multiple scenarios in themetrics storage 235.

The network operator may use the user interface 235 to access themetrics storage 235 to view various metrics data. The user interface 225may include a display to select and view metrics data. Further, the userinterface 225 may allow a network operator to use search queries tosearch for specific metrics data. Such ability to view and search themetrics data allows the network operator to determine the overall systemperformance and health. It might also provide information regardingperformance problems or errors in system operation.

A network operator may use the user interface 225 to create custommetrics rules. Such rules may extend existing predefined metricsscenarios. In such a case the existing predefined metrics scenarios maybe presented to the network operator using the user interface 225, andthe network operator may select additional AVPs to be collected in themetrics scenario. Additionally, the network operator may add additionalconditions to define the metrics scenario. Also, the predefined scenariomay serve as a template to create a new custom metrics scenario.

In addition, the network operator may define completely new custommetrics scenarios. Such scenarios may include the various conditionsthat define when the custom metrics scenario is present. In addition,the specific AVPs may be defined to determine the specific metrics datato be collected and stored.

The custom metrics rules may be implemented using a pseudo-coderepresentation of the rule. Such an implementation provides a networkoperator great flexibility in defining rules to meet variousrequirements and conditions. These custom metrics rules may use theinformation described above to evaluate whether the receipt of aDiameter message requires the collection of metrics data. The custommetrics rules may be as simple or complex as needed in order to satisfythe specific needs of the network operator.

In an alternative embodiment, the metrics collector 230 may evaluate thecustom metrics rules instead of the rule engine 220. Upon DN 200receiving a Diameter message to be processed, message handler 210 maypass information regarding the Diameter message to the metrics collector230. The metrics collector 230 may determine if the message fits withinany custom metrics scenarios as defined by custom metrics rules. If so,the metrics collector stores the metrics data specified by the custommetrics scenarios. It is possible that a single received Diametermessage may fit within more than one scenario. Accordingly, the metricscollector 230 may collect and store data for these multiple scenarios inthe metrics storage 235.

FIG. 3 illustrates an exemplary hardware diagram of a Diameter node 300.The exemplary DN 300 may correspond to the DN 200 of FIG. 2 or to DRA142 or the PCRBs 144, 146 that act as a PCRN of exemplary environment100 of FIG. 1. As shown, the hardware device 300 may include a processor310, memory 320, user interface 330, network interface 340, and storage350 interconnected via one or more system buses 360. It will beunderstood that FIG. 3 constitutes, in some respects, an abstraction andthat the actual organization of the components of the DRA 300 may bemore complex than illustrated.

The processor 310 may be any hardware device capable of executinginstructions stored in memory 320 or storage 350. As such, the processormay include a microprocessor, field programmable gate array (FPGA),application-specific integrated circuit (ASIC), or other similardevices.

The memory 320 may include various memories such as, for example L1, L2,or L3 cache or system memory. As such, the memory 320 may include staticrandom access memory (SRAM), dynamic RAM (DRAM), flash memory, read onlymemory (ROM), or other similar memory devices.

The user interface 330 may include one or more devices for enablingcommunication with a user such as an administrator. For example, theuser interface 330 may include a display, a mouse, and a keyboard forreceiving user commands.

The network interface 340 may include one or more devices for enablingcommunication with other hardware devices. For example, the networkinterface 340 may include a network interface card (NIC) configured tocommunicate according to the Ethernet protocol. Additionally, thenetwork interface 340 may implement a TCP/IP stack for communicationaccording to the TCP/IP protocols. Various alternative or additionalhardware or configurations for the network interface 340 will beapparent.

The storage 350 may include one or more machine-readable storage mediasuch as read-only memory (ROM), random-access memory (RAM), magneticdisk storage media, optical storage media, flash-memory devices, orsimilar storage media. In various embodiments, the storage 350 may storeinstructions for execution by the processor 310 or data upon with theprocessor 310 may operate. For example, the storage 350 may store ruleengine instructions 352 and rules 354 read and acted upon by the ruleengine. The storage 350 may also store custom metrics rules 356 for usein defining the custom metrics to be collected. It will be apparent thatvarious information described as stored in the storage 350 may beadditionally or alternatively stored in the memory 320. For example, thecustom metrics rules 356 may be additionally, alternatively, orpartially stored in memory 320. Various other arrangements will beapparent.

FIG. 4 illustrates an embodiment of a custom metrics rule. In theexample rule, the network operator is interested in recording metricsfor any messages requesting greater than 10 Mbps of download bandwidth.That interest is further scoped by differentiating between IMSI typesubscribers versus all other subscriber types. In this case, the networkoperator does not care about whether the request type is an initialrequest or an update, so for simplicity, the ‘Request Type’ metricattribute is removed. The custom metrics rule in FIG. 4 may firstdetermine if the message is requesting a download bandwidth greater than10 Mbps and if the subscriber is an IMSI type subscriber. If so, twometric attributes are added: Name=Subscription ID Type and Value=1; andName=QoS Range and Value=+10 Mbps range. In addition the Request Typemetric is removed. If the first condition is not met, the rule thendetermines if the message is requesting a download bandwidth greaterthan 10 Mbps. If so, one metric attribute is added: Name=QoS Range andValue=+10 Mbps range. In addition the Request Type metric is removed.

As shown in the above examples, custom metrics rules may be defined toallow for the custom collection of metrics data at Diameter nodes. Thecustom metrics rules may define a scenario, i.e., a definition ofconditions where certain metrics should be collected. Such scenarios maybe defined by the type of message received, the sender of the message,subscriber information, etc. Further, a specific set of metrics, e.g.,AVPs, to be collected may be defined for the scenario. Further, thecustom metrics may be defined as modifying existing predefined metricsscenarios or as completely new scenarios.

FIG. 5 illustrates an embodiment of a method of applying custom metricsrules. The method 500 may be performed by a DN. Within the DN the RuleEngine 215, message handler 210, Diameter stack 205, user interface,225, and/or metrics collector 230 may perform some of the steps inmethod 500. The method 500 may begin 505 and then may receive user inputregarding custom metrics rules 510. The user may include the completedefinition of custom metrics rules and the information used in thoserules. Also, a set of predefined custom metrics rule templates may bepresented to the user, and the user may select a predefined ruletemplate and provide information to be used to fully define the rule.Also, the user may select an existing predefined custom metrics scenarioand create a custom metrics rule to modify the existing predefinedcustom metrics scenario.

Next, based upon the user input, the method creates the custom metricsrule 515. The DN then may receive a Diameter message 520. Next, the DNmay apply the custom metrics rule to the received diameter message 525.The DN may then collect the custom metrics based upon the custom metricsrule 530. Then the method may end at 545.

It should be apparent from the foregoing description that variousexemplary embodiments of the invention may be implemented in hardware orfirmware. Furthermore, various exemplary embodiments may be implementedas instructions stored on a machine-readable storage medium, which maybe read and executed by at least one processor to perform the operationsdescribed in detail herein. A machine-readable storage medium mayinclude any mechanism for storing information in a form readable by amachine, such as a personal or laptop computer, a server, or othercomputing device. Thus, a tangible and non-transitory machine-readablestorage medium may include read-only memory (ROM), random-access memory(RAM), magnetic disk storage media, optical storage media, flash-memorydevices, and similar storage media.

It should be appreciated by those skilled in the art that any blockdiagrams herein represent conceptual views of illustrative circuitryembodying the principles of the invention. Similarly, it will beappreciated that any flow charts, flow diagrams, state transitiondiagrams, pseudo code, and the like represent various processes whichmay be substantially represented in machine readable media and soexecuted by a computer or processor, whether or not such computer orprocessor is explicitly shown.

Although the various exemplary embodiments have been described in detailwith particular reference to certain exemplary aspects thereof, itshould be understood that the invention is capable of other embodimentsand its details are capable of modifications in various obviousrespects. As is readily apparent to those skilled in the art, variationsand modifications can be effected while remaining within the spirit andscope of the invention. Accordingly, the foregoing disclosure,description, and figures are for illustrative purposes only and do notin any way limit the invention, which is defined only by the claims.

What is claimed is:
 1. A method performed by a Diameter node, the methodcomprising: receiving a Diameter message at the Diameter node;evaluating a custom metric rule to identify a metric to be collected;and collecting the metric related to the received Diameter message basedupon the evaluation of the custom metric rule.
 2. The method of claim 1,wherein the Diameter node is a diameter routing agent (DRA).
 3. Themethod of claim 1, wherein the Diameter node is a policy and chargingrules node (PCRN).
 4. The method of claim 1, further comprising,receiving, via a user interface, a definition of the custom metric rule,wherein the definition specifies the metric and a condition when themetric is to be collected.
 5. The method of claim 4, further comprising,receiving a plurality of Diameter messages at the Diameter node;collecting a plurality of values of the specified metric from a set ofDiameter messages in the plurality of Diameter messages that meet thespecified condition; and transmitting via a user interface the collectedplurality of values.
 6. The method of claim 4, further comprising,interfacing with an external node using a custom plugin; and wherein,the Diameter message is received from the external node, the custommetric rule is related to Diameter messages from the external node, andthe collected metric relates to the received Diameter message from theexternal node.
 7. The method of claim 4, wherein the definition of thecustom metric rule modifies a preexisting custom metrics scenario.
 8. ADiameter node (DN) for processing a Diameter message, the DN comprising:a rule storage configured to store a custom metrics rule that defines acustom metrics scenario; a Diameter stack configured to receive aDiameter message from another Diameter node; a rule engine configured toevaluate the custom metric rule to identify a metric to be collected;and a metrics collector configured to collect the metric related to thereceived Diameter message based upon the evaluation of the custom metricrule.
 9. The DN of claim 8, wherein the Diameter node is a diameterrouting agent (DN).
 10. The DN of claim 8, wherein the Diameter node isa policy and charging rules node (PCRN).
 11. The DN of claim 8, furthercomprising, a user interface configured to receive a definition of thecustom metric rule, wherein the definition specifies the metric and acondition when the metric is to be collected.
 12. The DN of claim 11,wherein, the Diameter stack is configured to receive a plurality ofDiameter messages from other nodes, the metrics collector is configuredto collect a plurality of values of the specified metric related to thereceived Diameter message based upon the evaluation of the custom metricrule, and a user interface configured to transmit the collectedplurality of values.
 13. The DN of claim 11, wherein, the Diameter stackis configured to interface with an external node using a custom plugin,the Diameter message is received from the external node, the custommetric rule is related to Diameter messages from the external node, andthe collected metric relates to the received Diameter message from theexternal node.
 14. The DN of claim 11, wherein the definition of thecustom metric rule modifies a preexisting custom metrics scenario.
 15. Anon-transitory machine-readable storage medium encoded with instructionsfor execution by a Diameter node (DN) for processing a Diameter message,the medium comprising: instructions for receiving a Diameter message atthe Diameter node; instructions for evaluating a custom metric rule toidentify a metric to be collected; and instructions for collecting themetric related to the received Diameter message based upon theevaluation of the custom metric rule.
 16. The non-transitorymachine-readable storage medium of claim 15, wherein the Diameter nodeis a diameter routing agent (DN).
 17. The non-transitorymachine-readable storage medium of claim 15, wherein the Diameter nodeis a policy and charging rules node (PCRN).
 18. The non-transitorymachine-readable storage medium of claim 15, further comprising,instructions for receiving, via a user interface, a definition of thecustom metric rule, wherein the definition specifies the metric and acondition when the metric is to be collected.
 19. The non-transitorymachine-readable storage medium of claim 18, further comprising,instructions for receiving a plurality of Diameter messages at theDiameter node; instructions for collecting a plurality of values of thespecified metric from a set of Diameter messages in the plurality ofDiameter messages that meet the specified condition; and instructionsfor transmitting via a user interface the collected plurality of values.20. The non-transitory machine-readable storage medium of claim 18,wherein the definition of the custom metric rule modifies a preexistingcustom metrics scenario.